In any telecommunications network, users will from time-to-time suffer poor quality service as a result of faults occurring in the network. For example, a user might experience a silent media plane, where both parties to a call cannot hear one another, or the media plane may be broken in only one direction. The ITU-T has published specifications for fixed systems which include definitions and probabilities for fixed network problems such as unacceptable transmission and interrupt; break (of service). The expected probability for unacceptable transmission is 0.001 percent in fixed networks. Users of cellular networks expect similar or better quality levels compared to fixed network offerings.
Network operators and kit vendors have of course implemented fault detection mechanisms in deployed networks in order to meet or improve upon the ITU-T targets. Examples include:                Using a Continuity Check for TDM and ATM connections to check the integrity of the speech path. This might involve injecting a tone into the speech signal at a first network node and detecting the tone at a second network node or when “reflected” back to the first network node. However, Continuity Check for TDM and ATM connections results in a perceptible degradation of speech and so it is usually performed before a call is actually performed (through-connected). It is not desirable to use Continuity Check to determine media loss during a call. [The Telecommunications Technology Committee, TTC, standard (which is used in Japan for example) does not include a Continuity Check function.] The continuity check is typically using the external connection handling part (Exchange Terminal (ET)) of the node and thus it cannot detect faults in the equipment, which is handling actual media processing such as speech transponders.        RTCP (Real-Time Control Protocol) for IP connections (e.g. Voice over IP, VoIP, calls). As set out for example in 3GPP TS 26.114 V8.3.0, for an RTP based media stream, RTCP packets may be used to deliver reports relating to a connection, between network nodes. Use of RTCP is optional in IP based Nb, Iu, A and Mb interface standards. In a multi-vendor environment, a node cannot know whether or not a peer node (over for example an Nb link between two Media Gateways) has actually activated RTCP or not. Also, RTCP requires extra bandwidth. It is also possible to use STUN (Simple Traversal of UDP through NATs (Network Address Translation)) to deliver reports on an IP connection. STUN is a protocol for assisting devices behind a NAT firewall or router with their packet routing. [RFC 5389 redefines the term STUN as ‘Session Traversal Utilities for NAT’.] BFD (Bi-directional Forward Detection) may also be employed for fault detection and reporting purposes, although the mechanism is not on a connection level (but on a node level instead) and so it cannot be used for supervision of connection level problems.        
There exist solutions for detecting hanging resources. One such mechanism is the H.248.36 package which allows a Media Gateway Controller to identify hanging connections within a Media Gateway. However, these kind of mechanisms are intended to be run in the background periodically, for example once per hour.
In summary, prior art solutions to fault detection in the media plane suffer from one or more of the problems of user data degradation, increased bandwidth, poor network-wide applicability, and lack of real-time reporting.